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r fmsA 

Challenger Accident Report 

FINDINGS 

• Problem reporting requirements are not concise and fail 
to get critical information to the proper levels of 

management. 

• Little or no trend analysis was performed on O-ring 
erosion and blow-by problems. 

• Five weeks after the 51-L accident, the criticality of the 
Solid Rocket Motor field joint was still not properly 
documented in the problem reporting system at Marshall. 


(June 6, 1986 p.152, pl61) 
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F7.4-9 

NASA information databases such as The Problem Reporting and 
Corrective Action and the Web Program Compliance Assurance 
and Status System are marginally effective decision tools 


F7.4-11 

The Space Shuttle Program has a wealth of data tucked away in 
multiple databases without a convenient way to integrate and use 
the data for management, engineering, or safety decisions. 


F6.1-10 

NASA failed to adequately perform trend analysis on foam losses. 
This greatly hampered the agency's ability to make informed 
decisions about foam losses. 
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Other Lessons Learned 


♦ Lesson Learned Shuttle, ISS, Orbiter 

♦ , Experiences during RTF after Challenger and Columbia 


/ 


- Significant cost incurred attempting to locate & capture H/W 
and S\W life-cycle failure history 

- Multiple databases with little or no access and no common 
terminology 


Significant cost incurred in trying to trend, (data-mining by 
several multiple organizations, produced marginal results) 


- Multiple instances of innovative ways to not report problems 

(i.e. "in-family" vs "out of family" ; reporting start at ATP and 
then only at highest level assembly.) 
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How the Cx PRACA Requirements Respond 
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♦ Defines PRACA PROCESS first then identifies tool needed 

♦ Requires a Single Tool for Managing the PRACA Data & Process 

Allowing data to be collected in different tools significantly complicates the process . 

♦ Clearly defines the Scope of PRACA Applicability and What ‘Problems” Must 
Be Reported 

The PRACA requirements specify those items to which the PRACA reporting and 
management process applies. 

♦ Clearly defines when the PRACA Process and Requirements become 
Applicable 

The PRACA reguirements define the point in time during HW/SW development that 
reporting and managing problems is reguired. 


♦ Clearly defines Ownership and Responsibility for Managing the PRACA 
Process , Including Disposition Authority 

Although all “problems” should be reported, not all problems warrant NASA 
disposition approval; those that do may warrant approval at different levels. 
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♦ Support, involvement and ownership by Program and Project Management 
Important aspects for success of closed-loop corrective action systems: 

• Enforce Accountability (NASA and Contractors) 

• Require thorough analysis and approval before deviating or allowing 
deviation from requirements 

• CxP PRACA is a Process, not a Database. The database is intended to 
support the tactical implementation of the process.* 

• Rigorous training on process and/or CxP PRACA Module 

• Ensure communication (NASA NASA 1 1 Contractor NASA). 

• Ensure appropriate resources through the life of the program 

Understanding of economic case as well as technical (safety) case for 
requirements. 

*CxP PRACA is a process, supported by a single information gathering data module which will be integrated 
with a single CxP Information System, providing interoperability, import and export capability making the 
CxP PRACA a more effective and user friendly technical and management tool. 
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Key Lessons Learned 

CXPRACA DATA SYSTEM 
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♦ Process 

/ • Single, centralized data set 

• Expanded definition of the types of captured problems (e.g., non- 
conformances) 

System 

• Tactical support for analysis and investigation 
• Workflow support 

• Highly modifiable, especially with respect to data collected and workflow 

• Interoperability with related systems (e.g., Parts list, PRACA, FMEA/CIL, 
Hazards, GMIP, CRADLE, etc.) 

• Attachments (any number, any size, any type) 

• Cross-platform, Cross-browser 
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Broad System Solutions/Issues 
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♦ Paper->Digital = New capability and options = Process 
changes 

jg Should collect low-level non-conformances 

• What seems like a small problem when looked at from a trending 
perspective may be a large issue. 

Manage hardware, software, process problems 
together 

• Creates environment for analysis across all problems. 

• The line between software and hardware is blurry and process connects to 
both. 

Adaptable for future technology 

• Protect the data, the software will change 

Open standards, focus on web services and 
interoperability 


Links to Relevant Data 
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♦ One linked PRACA data set across centers 

• Across Centers and workgroups 

• Linking dependencies in work process steps 

• Tying together related problems and parts 

Access from and to multiple related systems, 

I Attaching, accessing relevant files, e.g., diagrams, 
spreadsheets, telemetry 
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Flexible & powerful searching within the system 
Types of Search 

• Keyword (Google style) 

- Records which mention Newton 

• Filtering (most valuable for quality) 

- Every record ever entered pertaining to part SB00001, sorted by criticality and date 
entered 

• Suggestive Filtering 

- All records matching a set combination of fields in an opened record, automatically 
provided for review. 

• Relational Filtering 

- Comprehensive results utilizing correlated links between related problems 

• Integrated system supported search 

- Every record pertaining to a part included on the official flight manifest 
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♦ Providing definition of fields and code values in context with their 
use. 

• Clickable field titles with definition provided. 

• Value definition lists 

Validate data on entry against authoritative source 

• Part numbers checked against Product Data Structure 

• Invalid entrees stored but marked for evaluation 

Codes and Trending data need to be consistent and reliable 

• When possible have codes managed in an authorities, sharable source 

• Ensure consideration has been made for evolution of coding schemes 
(merging values, splitting values up) 

• Valuable for closed records to maintain original coding but function in 
searches based on up to date coding schemes. 


